This invention relates to emulation systems (emulators) used for developing microprocessor-based systems, and specifically to techniques and hardware for providing additional marking in memory to emulation analysis states used in emulators for analysis purposes during dequeueing and tracing operations.
Emulators aid the development of microprocessor-based systems (target systems) by providing means for designers to load and run software (target programs) before any hardware is built The emulator may substitute for part or all of the target system. Emulators may be connected to the target system at any point in the system's development. FIG. 1 is a block diagram of a generic microprocessor-based system, having microprocessor 10, memory 12, and input/output device 14. FIG. 2 is a block diagram of an emulation system, having emulator 18, host computer 20, and user terminal 22. FIG. 3 is a block diagram of an emulator connected to a microprocessor-based system. The emulator is plugged into the microprocessor socket 16 in the target system in place of microprocessor 10 shown in FIG. 1, and is supported by host computer 20. The emulator provides the microprocessor functions and some of the memory for the target system, since the user may not have any or all the target system memory functioning. As the development approaches completion, functions performed by the emulator are gradually transferred to the target system. During the development, the emulator provides additional microprocessor controls not usually available which are useful for troubleshooting target software problems, including: single stepping, break points for certain memory addresses, break points on improper memory accesses, displaying and modifying internal registers, etc.
One particular microprocessor control which is useful is called "instruction analysis". Instruction analysis consists of "tracing", which is the acquisition of a collection of states during execution of a target program; and disassembly, which is the analysis of the acquired collection of states following the execution of the target program by the microprocessor. Instruction analysis attempts to recreate the actual instruction process. The standard method of acquisition examines the instructions fetched prior to execution to acquire state information, which usually includes the address, data and status information of a single microprocessor cycle. However, there may be a significant difference between the instructions that are fetched and the instructions that are executed. The process of attempting to recreate instruction execution from instruction fetches is called "dequeueing".
One dequeueing method taught in the prior was called "hardware dequeueing". This method of dequeueing was an attempt to recreate the microprocessor queue with circuitry. This was difficult to accomplish, therefore time consuming and expensive, and not always accurate. Each hardware dequeuer was dependent upon the architecture of the target processor and consequently this difficult task was repeated for every design of a new emulator. Critical information about microprocessor architecture required for design was often not available, and many other processors had queues which could not be recreated in this manner.
A second dequeueing method taught in the prior art was known as "software dequeueing". This method of dequeueing would attempt to recreate the microprocessor queue by decoding the instruction fetch information captured in a trace. This method was substantially cheaper to implement than the hardware method of dequeueing, but had severe accuracy problems. A major reason for accuracy degradation was difficulty in dequeueing branch or conditional branch instructions, because branches in a queued microprocessor caused multiple unused instruction fetches, which resulted in the execution of instructions in a different order than the instruction fetch order. Other instructions included single words, double words, or long words (quadruple words), and instructions which had an argument (operand) associated with the instruction (as in an "add constant" instruction). Since decoding of the instruction fetch information typically began at a point chosen within the target program by the user, there was no method of determining that the first word was also the beginning of an instruction. If the first word was not the beginning of an instruction, the dequeuer would regardless interpret it as the beginning of an instruction. The frequent result was that the decoded instruction fetch information bore little resemblance to what was actually being executed by the processor in the target program. Consequently, the "software dequeueing" solution, although much less expensive than the "hardware dequeueing" solution, was extremely unreliable.